Several leading technology organizations are investing in building technologies that sell “software-as-a-service”. Such services provide access to shared storage (e.g., database systems) and/or computing resources to clients or subscribers. Within multi-tier e-commerce systems, combinations of different types of physical and logical resources may be allocated to subscribers and/or their applications, such as whole physical or virtual machines, CPUs, memory, network bandwidth, I/O capacity, or bundled resources such as database servers, scientific computation clusters, and the like.
In some storage-related service environments, a respective set of resources capable of supporting a desired rate of work operations may be provisioned for each storage object, such as a table or a storage volume. For example, in the case of network-accessible database services, a number of storage nodes may be established to store client database contents and to perform various types of reads, writes and other data extraction or manipulation operations on behalf of the clients. The storage nodes may each comprise one or more storage devices with respective performance characteristics. A client's data may be laid out or distributed among the storage devices and storage nodes such that, at least during normal operating conditions, a desired throughput goal and/or response time goals for reads and/or writes can be met. The desired throughput for a given storage object may be referred to as the provisioned throughput for that storage object.
The initial set of storage devices and nodes selected to store a given client's data may be based on the client's own initial estimate (or the service's estimate) of the expected workload, and/or the expected amount of data that the client expects to generate over some time period. In at least some environments clients may specify the provisioned throughput (e.g., reads per second and/or writes per second) for a storage object at the time that the storage object is created or initialized, and the resources set aside for the storage object may be determined based on the client's specifications. At least for certain kinds of applications, the manner in which clients access their data (e.g., which parts of their data are accessed more frequently than others over time, and the read-to-write ratios of such accesses) may change significantly with time, which may result in situations in which the initial workload estimates and specifications are no longer appropriate for resource management decisions.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.